[PWGHF] Species-dependent minimum prong pt cut in skimming#15755
[PWGHF] Species-dependent minimum prong pt cut in skimming#15755Marcellocosti wants to merge 10 commits intoAliceO2Group:masterfrom
Conversation
|
O2 linter results: ❌ 0 errors, |
Please consider the following formatting changes to AliceO2Group#15755
|
Hi @Marcellocosti, thanks! Please before merging this PR, it is important to profile the CPU consumption (for Pb-Pb especially). |
|
Hi @fgrosa, thanks for the suggestion! I just have a doubt: do you want me to profile the CPU consumption related to these code changes or to lower min-pt selections with respect to the ones currently used? Because with this implementation we will be anyway able to run with the min-pt selections used until now with no increase in CPU usage, given that just one check is added. And maybe hyperloop is best suited to monitor the impact of lowering the pt thresholds. |
I would say that at least you should check that without changing the cut (i.e. setting them all as we have now) it does not introduce an overhead. Then, I would suggest also to check what is the impact of lowering even only one since keep in mind that this usecase will be only useful for Pb-Pb, since in pp anyway there is no point in reducing it further. |
|
Okay, I will post here the checks you suggested before marking the PR as ready for review. For the use-cases, I was thinking more of lowering it in OO collisions (from the current 0.4 GeV/c), but of course it would be nice to see if also the Pb-Pb case can be lowered. |
|
Hi @fgrosa, I performed local tests reconstructing 55 Pb-Pb collisions in 0-20% centrality. I performed 3 tests and I report the
Please let me know if this is what you had in mind or if you think additional checks are required. Thanks a lot! |
Thanks @Marcellocosti! This shows that the implementation for the current cuts does not introduce overhead, so it's safe to be merged, but releasing the cut for central Pb-Pb collisions increases x3 the time, so it is prohibitive unless we implement other optimisations. This might instead work for OO however, given the lower combinatorics. |
fgrosa
requested review from
NicoleBastid,
alibuild,
apalasciano,
deepathoms,
fcatalan92,
fcolamar,
fgrosa,
gluparel,
hahassan7,
jpxrk,
mfaggin,
mmazzilli,
singhra1994,
stefanopolitano,
vkucera and
zhangbiao-phy
as code owners
|
Hi @vkucera, thanks for the feedback, I have implemented your comments! |
Implement Vit comments
vkucera
left a comment
vkucera
left a comment
There was a problem hiding this comment.
Thanks for the updates. After the clarification, I also understand better what labels represent what. Please see my updated suggestions.
|
Thanks @vkucera, I have implemented your comments! |
|
|
||
| // Single prong min pt selection | ||
| static constexpr int NSpecies = 8; // number of species for 3-prong candidates | ||
| constexpr float ptProngMin[NSpecies][1] = {{0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}}; |
There was a problem hiding this comment.
| constexpr float ptProngMin[NSpecies][1] = {{0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}}; | |
| constexpr float PtProngMin[NSpecies][1] = {{0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}, {0.4f}}; |
There was a problem hiding this comment.
Thanks, fixed!
| if (ptProngs[0] < ptProngMin || ptProngs[1] < ptProngMin || ptProngs[2] < ptProngMin) { | ||
| CLRBIT(isSelected, iDecay3P); | ||
| if (config.debug) { | ||
| cutStatus[iDecay3P][4] = false; |
There was a problem hiding this comment.
This seems like you are using an existing reserved slot. Should you not extend the numbers of cuts instead?
5 participants
This PR implements the possibility to have different minimum prong pt selections for the HF 3 prong candidates in the
trackIndexSkimCreatorworkflow.